1. Field of the Invention
The present invention relates generally to a Broadcast/Multicast Service (BCMCS) method and system in a mobile communication system, and in particular, to a BCMCS method and system for providing a mobile station with various status information indicating whether a BCMCS service is available and whether a BCMCS service is stopped due to a system abnormality within a broadcasting network.
2. Description of the Related Art
A broadcasting overhead message used in the conventional BCMCS system must include identification information (hereinafter referred to as a “BCMCS Flow ID”) for all available BCMCS content regardless of whether a service is actually in progress in each cell when Dynamic BCMCS is used. The broadcasting overhead message can be classified into Broadcast System Parameters Message (BSPM) used in a 1x BCMCS system and Broadcast Overhead Message used in a High-Rate Packet Data (HRPD) BCMCS system.
In the following description, the “1x BCMCS system” refers to a BCMCS system based on CDMA 2000 1x Rev.A/B or 1x EV-DV (Evolution Data and Voice), i.e., CDMA 2000 1x Rev.C/D, and the “HRPD BCMCS system” refers to a BCMCS system based on 1x EV-DO (Evolution Data Only).
If a desired BCMCS Flow ID is included in the broadcasting overhead message, a mobile station (or access terminal) determines that it can receive a corresponding BCMCS service, and transmits a Broadcast Registration message to a base station (or access network). The mobile station determines whether it can receive a BCMCS service using the BCMCS Flow ID because there are no other methods capable of informing a mobile station whether it can receive a BCMCS service, excepting the broadcasting overhead message.
The HRPD BCMCS system uses a Broadcast Reset message. For example, the Broadcast Reset message is transmitted to an access terminal when broadcasting-related session information is changed in a broadcasting network and when the access terminal moves to a cell where its previous broadcasting-related session information is invalid.
In the HRPD BCMCS system, negotiation on configuration information of protocols should be made while carrying out configuration negotiation for Unicast Service or immediately after a traffic channel is set up to access a BCMCS controller in order to receive a BCMCS service. While a BCMCS service is being provided, because the access terminal operates in an idle status, configuration negotiation over broadcast protocols is not performed.
As described above, in the conventional BCMCS system, because only the broadcasting overhead message can be used for informing a mobile station of the availability of a BCMCS service, each cell must include information on all available broadcast channels in order to provide Dynamic BCMCS, causing an increase in the length of the broadcasting overhead message. The increase in length of the broadcasting overhead message inevitably increases loads on a paging-related channel in the 1x BCMCS system and a control channel in the HRPD BCMCS system.
Additionally, when a BCMCS service is stopped due to a system failure or mobile station failure(s), the conventional BCMCS system has no way to inform a mobile station of the failure(s). For these reasons, the conventional BCMCS system must depend on reception performance of a mobile station or recognition of a user of the mobile station in determining whether a BCMCS service can be normally received.
Further, when using the Broadcast Reset message the BCMCS system must perform a process in which the access terminal sets up a traffic channel and accesses the BCMCS controller. In this method the time required for user recognition to occur is greatly increased, thereby inconveniencing the user. Further, even in the state where a BCMCS service is unavailable, a BCMCS-related message is transmitted to the access terminal and a traffic channel is set up unnecessarily, wasting system resources.
In the HRPD BCMCS system, an access terminal performs configuration attribute negotiation for each protocol only when it transmits traffic, i.e., only when it performs data communication. In an idle status where the access terminal does not perform data communication, because there is no way to negotiate an attribute value and the access terminal has not performed negotiation with an access network over a configuration attribute of a broadcast protocol, the access terminal cannot receive a BCMCS service. In contrast, an access terminal that has performed attribute negotiation by performing data communication can receive a BCMCS service. That is, while receiving a BCMCS service, although the access terminal stays in an idle status for data traffic other than that for a BCMCS service, the access terminal can receive broadcast traffic using information on a configuration attribute, which was acquired through previous negotiation.
In some cases, an access terminal receiving a BCMCS service through the session negotiation needs to perform a new negotiation over an attribute value while receiving broadcast traffic. However, because negotiation over an attribute value should be made through only a traffic channel, an access terminal currently receiving broadcast traffic cannot perform a negotiation with an access network over an attribute of a new configuration value. In this case, because the access terminal cannot perform a negotiation over an attribute of a configuration value, when it is necessary to change the attribute of a configuration value, a normal BCMCS service may not be achieved.
Access terminals have different update points for an attribute of a configuration value. Because the update for an attribute of a configuration value is restrictively performed according to data traffic, a particular access terminal may not continuously update session information. In this case, an access network providing a BCMCS service may experience difficulty in managing the BCMCS service.
As described above, in the conventional BCMCS system, a broadcasting overhead message used to transmit BCMCS-related wireless information such as BSPM to a mobile station is undesirably large. Additionally, when a BCMCS service is abruptly stopped due to a failure of a broadcasting network or a BCMCS server, or due to a lack of wired and/or wireless resources for transmitting broadcast traffic, there is no way to inform the mobile station of the status.